Skip to content

SPQR: build factors with typed constructors, for type-stability - #756

Open
topolarity wants to merge 2 commits into
JuliaSparse:mainfrom
topolarity:ct/trim-spqr
Open

SPQR: build factors with typed constructors, for type-stability#756
topolarity wants to merge 2 commits into
JuliaSparse:mainfrom
topolarity:ct/trim-spqr

Conversation

@topolarity

@topolarity topolarity commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Last PR of the --trim set!

Having the types spelled out explicitly here allows these constructors to be fully inferred w.r.t. dispatch. This does not affect the return type of any call, so no @inferred test is included.

This commit was written with the assistance of generative AI (Claude) 🤖

@codecov

codecov Bot commented Sep 2, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.99%. Comparing base (c0a1be5) to head (ed2e55a).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #756      +/-   ##
==========================================
- Coverage   84.08%   83.99%   -0.09%     
==========================================
  Files          13       13              
  Lines        9367     9367              
==========================================
- Hits         7876     7868       -8     
- Misses       1491     1499       +8     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@araujoms

araujoms commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Wait, why does the function accept Tv<:CHOLMOD.VTypes if it doesn't actually support them? It should be restricted to Float64 and ComplexF64, with Float32 and ComplexF32 handled by an explicit conversion like Float16 and ComplexF16 below.

topolarity and others added 2 commits September 3, 2026 16:49
SPQR only computes in double precision: its C entry points instantiate the
`double` templates and never inspect the matrix `dtype`. Since single precision
support was added, `qr` passed `Float32` and `ComplexF32` matrices through as
single-precision CHOLMOD matrices, which SPQR then read as doubles and returned
garbage factors for (a `Float32` diagonal of 1, 2, 3 came back as
`R = [2.0000005 0 0; 0 0 0; 0 0 0]`). The regression test only compared element
types, so this went unnoticed.

Restrict the SPQR method to `Float64` and `ComplexF64`, and route the narrower
real and complex types through an explicit conversion to double precision,
converting the factors back afterwards, as was already done for `Float16`.
The converted methods also accept `ordering`, as the double methods do.

This commit was written with the assistance of generative AI (Claude).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
`qr` wrapped SPQR's result pointers with the untyped `Sparse(ptr)` and
`Dense(ptr)` constructors, which read the element type from the C struct and
so dispatch dynamically. SPQR is only ever handed double precision input now
and returns factors of the same type, so use the typed constructors, which
also check that the returned `xtype` and `dtype` are the expected ones.

This commit was written with the assistance of generative AI (Claude).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@topolarity

Copy link
Copy Markdown
Contributor Author

You're right. This is broken right now:

julia> qr(SparseMatrixCSC{Float32}(sparse([1,2,3],[1,2,3],[1.0,2.0,3.0]))).R
3×3 SparseMatrixCSC{Float32, Int64} with 1 stored entry:
 2.0       
          
          

julia> qr(SparseMatrixCSC{Float64}(sparse([1,2,3],[1,2,3],[1.0,2.0,3.0]))).R
3×3 SparseMatrixCSC{Float64, Int64} with 3 stored entries:
 1.0       
     2.0   
         3.0

I have pushed a quick fix to the branch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants